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ABSTRACT 



Method (100) executed by congestion controllo: (26) in each 
node (20, 30, 40) of a network (10) determines whether 
. congestion is going to occur or is occuning in a particular 
node (20, 30, 40). If congestion is imminent or occurring, a 
congestion status bit is set. Each time a data packet is 
received and the congestion indicator bit is set, congestion 
controller (26) increments a congestion counter. Eadi time 
a predetermined time interval expires, congestion controller 
(26) decrements the congestion counter. By using the con- 
gestion counter as an index into a credit table, a credit value 
is determined by destination node (31) that represents how 
many data packets are pcnnittcd to be sent from source node 
(30) to destination node (31). The credit value is sent to the 
source node via a message. 

14 Oaims, 3 Drawing Sheets 
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APPARATUS AND METHODS FOR *'beam'* and "antenna pattern" are not intended to be limited 

PREDICTING AND MANAGING ^ any paiticolar mode of generation and include those 

CONGESTION IN A NETWORK created by either terrestrial or space-based telecommunica- 

tion systcmiS and/or combinations thereof. 
TECHNICAL FIELD 5 FIG. 1 shows a general view of space-based telecommu- 

nication system 10 according to a preferred embodiment of 
This invention relates generally to nodal networks and, in the present invention. Although FIG. 1 iUustrates a highly 
particular, to an apparatus and methods for predicting traffic simplified diagram of mobile telecommunication system 10. 
congestion and managing network traffic in a network. system 10 conqsises at least one satellite 20, any number of 

subscriber units 30 and at least one ground station 40. 
BACKGROUND OF THE INVEOTION GeneraUy, telecommunication system 10 may be viewed as 

^^^^^tur ^ network of nodes. Nodes are represented as satellites 20, 
Most conventional communxcation systems, especially ^i, subscriber units 30, 31 and gr^nd station 40. All nodes 
space-based mobile telecommumcation systems are of communication system 10 ie or may be in data corn- 
designed to handle a specific traffic Ic^d under nonnal ^.^eation with odicr nodes of comnmiication system 10 
<^tion conditions. However, under adverse conditions is throM^ communication links. In addition, all nodes of 
(e.g., cross-link or satellite failures) during unanticipated tdccomraunication system 10 are or may be in communi- 
traffic loads (e,g., constant data traffic), the network may cation with othCT telephonic devices dispersed throughout 
experience traffic congestion or overloading, thus resulting the world through public service telephone networks 
in data packets getting destroyed. If data packets are (PiSTNs) and/or conventional terrestrial communication 
destroyed, voice quality may significantly deteriorate or data 20 devices coufded to a PSTN through conventional terrestrial 
messages may become incomplete. Thus, there is a signifi- ground stations. 

cant need for a way to predict when traffic congestion will The present invention is applicable to space-based tele- 
occur and reduce traffic into node of the network to avoid communication systems that assign particular regions on the 
traffic congestion and loss of data packets. earth to specific cells on the earth, and preferably to systems 

23 that move cells across the surface of the earth. Although the 
BRIEF DESCRHTION OF THE DRAWINGS present invention is applicable to space-based telecommu- 

„^ ^ ^ 1 J r I. J i-i nication systems 10 having at least one satellite 20 in 

FIG. 1 shows a general view of a space-based mobde low^arth/medium-earth or geosynchronous orbit, sateUite 
telecommunication system acc<ffdmg to a preferred embodi- jO is preferably in low-eaith orbit around earth. Satellite 20 
mcnt of the present invention; jnay be a single satellite or one of many satellites in a 

FIG. 2 shows a general view of the components of a node constellation of satellites orbiting earth. The present inven- 
according to preferred embodiment of the present invention; tion is also applicable to space-based telecommunication 

FIG. 3 shows a flowchart of a method for monitoring systems 10 having satellite 20 whidi orbits earth at any 
network traffic and predicting traffic congestion according to angle of inclinatioD including polar, equatorial, inclined or 
a |ffcf erred embodiment of the present invention; 33 other orbital patterns. The present invention is applicable to 

FIG. 4 shows a flowchart of a method for receiving a data systems 10 where full coverage of the eardi is not achieved 
packet and incrementing a congestion counter according to ('^^^ wh<^ are 'Holes in the telecommunication 
a i»cferred embodiment of the present invention; coverage provided by die co^tellation) and to systems 10 

\^r. ^ ^ *i where plural coverage of portions of the earth occur (i.e., 

FIG, 5 shows a flowchart of a method for decrementing a v' ^ ^„ .0 i« ^•^«, « r^i«t /^« 

. , ^ -r J J' r An more than one satellite IS in view or a particular pomt on the 

congestion counter accordmg to a prefeircd embodunent ctf ^ earth's surface) 

the present invention, . . , . . . Each satellite 20 communicates with other nearby satel- 

HG. 6 shows a flowchart of a method for detcnmmng ^1 through cross-Unks 25. These cross-links 25 foim a 

how many data packets can be sent by a source node to a backbone of space-based mobile telecommunication system 
destinationnodcaccordingtoaprcfencdembodmientofthe 10. Hms, a caU or communication from one subscriber unit 
present invention; and located at any point on or near the surface of die earth 

FIG. 7 shows an exan^le of a aedit Uble. may be routed throu^ a satellite 20 or a constellation of 

satellites 20, 21 to another subscriber unit 31 (which is 
receiving the call) on or near the surface of the earth from 
50 another satellite 21. How satellites 20, 21 physically com- 
The present invention has utility in that it monitors traffic municatc (e.g., spread spectrum technology) with subscriber 
into each of the nodes of a network, predicts when conges- units 30, 31 and ground station 40 is well known to those of 
tion is going to occur in a node and manages the network ordinary skill in the art 

traffic through the nodes to avoid traffic congestion. By Subscriber units 30, 31 may be located anywhere on the 
detecting when congestion is likely to occur, the data packet 55 surface of earth or in the atmosphere above earth. Mobile 
traffic is managed so that data pckets are not destroyed or telecommunication system 10 may accommodate any num- 
lost ber of subscriber units 30, 31. Subscriber units 30, 31 are 

A ^'satellite** as used throughout this description means a preferably communication devices capable of receiving 
man-made object or vehicle intended to orbit the earth. A voice and/or data from satellites 20, 21 and/or ground station 
"satellite" comprises geostationary, low-eaith and medium- 60 40. By way of exaiiq>le, subscriber units 30, 31 may be 
earth orbiting satellites and/or combinations thereof. A **con- hand-held, mobile satellite cellular telephones ad^ted to 
stellation** means a number of satellites arranged in orbits transmit to and receive transmissions from satellites 20, 21 
for providing specified coverage (e.g., radio communication, and/or ground station 40. Moreover, subscriber units 30, 31 
remote sensing, etc.) of a portion, portions or all of the earth. may be machines capable of sending email messages, video 
A constellation typically includes multiple rings (or planes) 65 transmitters or facsimile units, just to name a few. 
of satellites and may have an equal number of satellites in How subscriber units 30, 31 physically transmit voice 
each plane, althou^ this is not essential. The terms "cell^*, and/or data to and receive voice and/or data from satellites 



DESCRIFnON OF THE PREFERRED 
EMBODIMENTS 



06/08/2004, EAST Version: 1.4.1 



5,751,969 

3 4 

20, 21 is well known to those of ordinaiy skill in the art. In when congestion is going to occur and manage nodal and 
the prefcued embodiment of the present invention, sub- network traffic to avoid traffic congestion. Antenna 21, 
scribcr unit 30 commuoicatcs with satellite 20 using a transceiver 22, processor 23, memory 24 and buffers 25 are 
limited portion of the electromagnetic spectrum that is all well known to those of ordinaiy skill in the art 
divided into numerous channels. The channels are prefer- 5 Although the preferred embodiment uses congestion con- 
ably combinations of L-Band, K-Band and/or S-band £rc- troUer 26, in alternative embodiments, congestion controller 
qucncy channels but may encompass Frequency Division 26 may be replaced by processor 23 if processor 23 is 
Multiple Access (FDMA) and/or Time Division Multiple capable of performing the same functions as congestion 
Access (TDMA) and/or Code Division Multiple Access controUex 26. Processor 23 could monitor, predict and 
(CDMA) communication or any combination thereof. Other manage traffic congestion similar to what is performed by 
methods may be used as known to those of ordinary skill in congestion controller 26, 

the art FIG. 3 shows a flowchart of method 100 fw monitoring 
Ground station 40 communicates with and controls sat- network traffic and predicting traffic congestion according to 
eUitc 20. Although ground station 40 could also control a preferred embodiment of the present mvention. Mediod 
satdHte 21, a different ground station 40 may control 15 100 is executed by congestion controller 26 in each of the 
satellite 21 ITiere may be multq)le ground stations 40 nodes (e.g.,satemtc 20, ground station 40, etc.) m a netwojt 
located at different regions on the earth. For exan^Jle, there Congestion controUcr 26 is executing an executable soft- 
may be one ground station 40 located in Honolulu, another ware version of method 100 shown m HG. 3, The conges^ 
located in Los Angdcs and another in Washington, D.C. tion controUer is executing method 100 conottrently with 
Another example is to have separate ground stations 40 ^ other programs, includmg method infra), 
located in eachcountry on the earth. Ground stations 40 may metiiod 160 (FIG. 5, infra) and method 170 (nG. 6, mfra). 
provide sateUite control commands to satellites 20, 21 so The congestion controller begins m step 102 by momtor- 
that satellites 20» 21 maintain their proper position in tiieir ing the buffers and determining how the buffen are cunciiay 
orbit and perform otiier essential house-keeping tasks. being used. Usage of a buffer is determined by examining 
Ground stations 40 may be additionally responsible fw 25 how much and how quickly data packets are being received 
receiving voice and/or data from sateUites 20, 21. How or transmitted through the buffers at the present time. Once 
ground station 40 physically communicates (e.g., spread buffer usage information is obtained in step 102, the con- 
spectrum) with satellites 20 and/or subscriber units 30 is gestion controller determines in step 104 whether congesUon 
weU known to those of ordinary skill in the art. is imminent or is occurring. This step is determined by usmg 
HG 2 shows a general view of the components of a node 30 algorithms that predict, based on the current statistical trends 
according to a prefctied embodiment of the i^csent inven- of buffer usage, whether traffic congestionis about to happen 
tion. A node includes, but is not limited to, satellites 20, 21, or if traffic congestion is occumng. 
subscriber units 30, 31 and ground station 40. For purposes An example of how congestion controUer determines in 
of this discussion, reference will be made to sateUite 20, step 104 whetiier congestion is likely to occur in a node is 
although most of the components are similar to those in 35 as foUows. First, each node takes at periodic mtervals a 
ground station 40. SateUite 20 comprises at least ffie fol- sn^shot of its resources. Second, when congestion occurs, 
Jawing components: antennas 21, transceivers 22, processor tiie congestion controUer examines the snapshots taken over 
23 memory 24, buffers 25 and congestion controUer 26. a period of time, say five seconds, for example. Third, from 
There may be other con^nents of satclUte 20 tiiat arc not tiie snapshots taken over the period of time, a profile of 
shown which m necessary for operating a sateUite but are 40 resource depletion is determined. HnaUy, wl^ the profile is 
not inroortant to the present invention. These other compo^ repeated at a future time, congestion of traffic passmg into 
ncnts are well known to tiiose of ordinaiy skiU in tiie art, and tiirough the particular node is predicted to occur. In 
including for exan^le, solar arrays and fiiel propulsion otficr words, the congestion controUer predicts that conges- 
system in satclUtes 20, or switches and network routers in tion is imminent based on a comparison of the previous 
ground station 40. Moreover, tiiere may be radre than one of 45 resource depiction profile and tiie current profile of resource 
the con^Kxients in sateUite 20, such as multiple processors depletion. 

23, for example. If congestion controller determines that congestion is 
Each of antennas 21 of satelUte 20 is coupled to its own imminent or is occurring in step 104, the congestion con- 
transceiver 22. Each of the transceivers 22 are coupled to its troUcr sets in step 106 a congestion status bit which mdicates 
own buffer 25. Buffers 25 arc coupled to each other, and to 50 tiiat congestion is imminent The congestion status bit is 
processor 23, memory 24 and congestion controUer 26. stored in either tiie congestion controUcr, memory or some 
Transceivers 22 are able to transmit or receive data or voice, otiicr part of a node. When tiie congestion status bit is srt m 
and may be for exanmle, a modem- Each of the transceivers a particular node, the congestion controUer sets a congestion 
22 may be assigned to receive data packets from another indicator bit in each data packet tiiat is passing tiirough tiie 
satellite 20, subscriber units 30 or ground sUtion 40. For 55 particular node. 

exanqde, transceiver 22 shown on die right in HG. 2 may be If congestion is not imminent cff is not occurring as 

used for cross-link communication, while transceiver 22 determined by tiie congestion controller in step IW, ttie 

shown on ttie left in FIG. 2 may be a feeder link. congestion status bit is cleared in step 108. When ttie 

Processor 23. via an executable software program, con- congestion status bit is not set in a particular riode, the 

trols ttie operation of sateUite 20 and die otiier conqwnents 60 congestion controUer docs not set tiie congestion mdicator 

of sateUite 20. Mcmoiy 24 stores executable software pro- bit in each data packet tiiat is passing through tiie parttcular 

grams and otiier sateUite information. Buffers 25 store in the node. However, if a data packet received at a node has its 

Sterim data packets received by transceivers 22 « data congestion indicate bit already set by a previous node, and 

packets from memory 24 which arc to be transmitted. tiie congestion status bit attiic node is not set, the congestion 

Congestion controUcr 26 conqjrises at least a processor and 65 indicator bit is not cleared. The congestion indicator bit, if 

memory. Congestion controUer 26 executes a variety of previously set, wUl continue to be set until it amves at the 

software programs that monitor network traffic, predict destination node. 
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For example, suppose subsciiber unit 30 was communi- 
cating with subscriber unit 31 through satellites 20 and 21 
(i.e., intermediary nodes). Further suppose that satellite 20 
(ffedicted that congestion was imminent and set its conges- 
tion status bit while satellite 21 predicted that congestion 
was not imminent and did not set its congestion status bit 
Thus, whenever satellite 20 receives data packets from 
subscriber unit 30 it sets the congestion indicator bit before 
the data packets are transmitted to satellite 21. Satellite 21 
does not dear the congestion indicator bit included in the 
data packets, but transmits the data packets with the con- 
gestion indicator bit set to subscriber unit 31. In other words, 
the congestion bit is not cleared by satellite 21 even though 
the congestion status bit of satellite 21 is cleared. 

Once the congestion controller finishes executing steps 
10€ and 108, method 100 returns to step 102 to continuously 
monitor buffer usage and determine whether traffic conges- 
tion is inuninent in step 104. Method 100 continues indefi- 
nitely. 

FIG. 4 shows a flowchart of method ISO for receiving a 
data packet and inaementing a congestion counter accord- 
ing to a prcfcned embodiment of &e present invention. 
Method 150 is performed by the congestion controller (26 in 
FIG. 2) in each of the nodes in a network concurrently with 
tiie execution of method 100 (FIG. 3, supra), method 160 
(FKj. 5, infra) and method 170 (HG. 6, infra). Method 150 
is executed by the congestion controller any time a data 
packet is received at the node. The congestion controller 
begins in step 152 by waiting until a data packet is received. 
A data packet is received at an antenna, which is sent to a 
transceiver and a cocrespondiiig buffer. (See FIG. 2). 

Once a data packet is received, the congestion controller 
in step 154 determines whether the congestion indicator bit 
of the data packet is or is not set If the congestion indicator 
bit is not set, the congestion controller returns to step 152 to 
wait until another packet is transmitted. When the conges- 
tion indicator hit is not set, it indicates that congestion is not 
predicted to be imminent or is occurring in this particular 
node at this time. If there is no congestion, there is no need 
to manage the data packet traf&c. 

If (he congestion indicator bit is set, it means that traffic 
congestion may be occurring or is going to occur in the node 
and possibly in the network. If the congestion indicator bit 
is sety the congestion controller increments the congestion 
counter in step 156. The congestion counter monitors the 
volume of data packets that are being received by a node. 
Each time a packet is received and the congestion indicator 
bit is set, the congestion counter is incremented. The con- 
gestion counter is used as an index into a table that has credit 
values indicating whether the destination node wants the 
source node to send more or less data packets. 

Once the congestion counter is inaemented in step 156, 
the congestion controller returns to step 152 and waits until 
another data packet is received. Method 150 continues 
indefinitely. 

FIG. 5 shows a flowchart of method 160 for decrementing 
a congestion counter according to a preferred embodiment 
of the present invention. When the congestion counter is 
decremented at predetermined time intervals, it indicates 
that data packet traffic through a particular node is becoming 
less congested. Mediod 160 is performed by the congestion 
controller (26 in FIG. 2) in each of the nodes of a network 
concurrently with the execution of metibod 100 (FIG. 3, 
supra), method 150 (FIG. 4, supra) and method 170 (FIG. 6, 
infra). Method 160 begins in step 162 by waiting for a 
predetermined time interval to expire. The predetermined 
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time interval may be set to a specific number, such as one 
second for exani^de. or may be changing, such as waiting 
one second during a first time interval, waiting two seconds 
during a second time interval and waiting five seconds 
3 during a third time interval 

Once the time interval expires in step 162, congestion 
controller decrements in step 164 the congestion counter. By 
dcaementing the congestion counter, the congestion con- 
troller is acknowledging that more data packets can be sent 
from the source node to the destination node. After decre- 
menting the congestion counter in step 164, congestion 
controller determines in step 166 whether the congestion 
counter is less than zero. If the congestion counter is not 
zero, method 160 returns to step 162 to wait for the next time 
interval to expire. If the congestion counter is less than zero, 
the congestion controller sets the congestion counter to zero 
in step 168 and returns to step 162. Method 160 continues 
indefinitely. 

FIG. 6 shows a flowdiart cf method 170 for determining 
how many data packets can be sent by a source node to a 
destination node according to a preferred embodiment of the 
present invention. Method 170 is performed by the conges- 
tion controller (26 in FIG. 2) in each of the destination nodes 
of a network concurrentiy with the execution of mettiod 100 

^ (see FIG. 3, supra), method 150 (see FIG. 4. supra) and 
method 160 (FIG. 5, supra). 

FIG. 2 shows one exan^e of source and destination 
nodes. In FIG. 2» suppose subscriber unit 30 was the source 
node, while subscriber unit 31 was the destination node. 

3Q Further suppose satdlites 20 and 21 were intermediary 
nodes. Since subscriber unit 30 is a source node, this means 
that subscriber unit 30 is transmitting data packets to satel- 
lite 20, satellite 20 is transmitting the data packets to satellite 
21, and satellite 21 is transmitting the data packets to 

33 subscriber unit 31, the destination node. Subscriber unit 31 
is responsible for executing method 170 shown in FIG. 6 and 
telling subscriber unit 30 (e.g., the source node), bow many 
data packets to send when netwc^k congestion is imminent 
or is going to occur. 

40 In the preferred embodiment, method 170 begins in step 
172 by waiting f receipt of a predetermined number of data 
packets. The predetermined number of data packets can be 
set to one, a number equivalent to the size of available space 
in the receive buffer, or some other number. The predeter- 

45 mined number of data packets could also be set to a credit 
value (explained below) or some variation thereof. In an 
alternative embodiment, step 172 may be rq)laced by an 
expiration of a time interval, similar to step 162 of FIG. 5. 
In another alternative embodiment, step 172 may be acti- 

50 vated when the destination node transmits an acknowledg- 
ment back to the source node that indicates diat the data 
packet or packets were received. 

Once a predetermined number of data packets are 
received by the node in step 172, the congestion controller 

55 determines in step 174 a credit value. Hie credit value 
represents how many data packets the destination node is 
going to tell the source node to send so that tiie network or 
intermediary nodes do not become congested or less con- 
gested. The credit value is one of many values listed in a 

60 credit table that are determined from simulations of the 
network congestion or data packet load. The credit values 
indicate how n^y data packets should be sent when net- 
work and nodal traffic arc at a predetermined data packet 
rate, as indicated by the congestion counter. The congestion 

65 counter is used as an index into the credit table. 

FIG. 7 shows an exan^le of credit table 200. Each 
congestion counter value in column 201 corresponds to a 
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credit value in column 2*2. For example, when the conges- the credit value if the credit value is less than oc equal 

tion counter is **V\ the credit value is determined to be '^O" to the available buffer space in the destination node, 

data packets. This may mean that the network is not and sending the message to the source node indicating 

congested, thus more data packets can be sent by the source that the source node can send the nunnber of data 

node to the destination node. If the congestion counter is 5 packets equivalent to the available buffer space in the 

*T\ the credit value is "1" data packet This may mean that destination node when the credit value is greater than 

the network is congested, dius only one data packet can be the available buffer space in the destination node, 

sent by the source node to the destination node to avoid 2. A method as recited in claim 1, wherein step (a) 

destruction of or lost data packets. includes the steps of: 

Once the aedit value is determined in step 174, conges- ^0 al) monitoring current buffer usage at each of the nodes; 

tion controUa determines whetho- the credit value is less and 

than or equal to the available buffer space in the receive a2) eadi of the nodes determining whether congestion is 

buffers. If the credit value is less than or equal to the imminent based on a comparison of a profile of the 

available buffer space, congestion controller sends in step current buffer usage with a profile of buffer usage when 

178 a message to the source node (i.e., the node sending the congestion is imminent. 

data packets to the destination node), teUiog the source node 3. A method as recited in claim 1, wherein step (a) 

to send a number of data packets equivalent to the credit con^iriscs the steps of. 

value. Otherwise, if the credit value is greater than the setting a congestion status in a node when congestion is 

available buffer space, congestion controller sends in step imminent in the node; and 

180 a message to the source node indicating that the source 20 ^^^g congestion status in the node when conges- 
node can send a number of data packets equivalent to tht ^^^^ ^^^^ imminent in the node, 
remaining, available buffer space. 4. A method as recited in claim 3, further comprising the 

As shown in FIG. 6, once congestion controller executes steps of; 

step 178 or 180, method 170 returns to step 172 to wait foi ^ach of the nodes waiting untfl a data packet is received; 

receipt of a predetermined number of data packets, or the ^j^^ determining whether its congestion 

number of data packets as detcrBiincd in Step 178 or 180. status is set; and 

Method 170 continues indefinitely, '^^^ incrementing its own congestion 

It will be appreciated by those skiUed in the art that the counter when the congestion status is set 

present invention includes a congestion controller and mcth- 5 ^ method as recited in claim 3, further conqirising tiie 

ods for monitoring data packet traffic flow, predicting when ^^^p ^^^^ ^ congestion indicator hit in a data packet that 

congestion is likely to occur and managing data packet is to be transmitted from a first node to a second node when 

traffic flow so that congestion does not occur. A congestion congestion status is set in the first node, 

indicator hit is set before congestion is likely to occur so tfiat 6. A method as redted in daim 1. wherein step (a) further 

traffic congestion can be avoided. Thus, it is an advantage of includes the steps of: 

the present invention to monitor traffic flow and activate ^ congestion status if congestion is occurring; and 

steps to avoid traffic congestion. It is an^er advantage of ^ congestion status if congestion is not occur- 

the present invenUon to predict when traffic congestion will ^ so 

occur and reduce taiffic into the network to avoid fraffic 7. Amethod as redted in claim 6, further comprising the 

congestion. Yet another advantage of the present invention 15 ^ steps of- 

to monitor traffic for congestion and to activate steps to ^ the nodes waiting until a data packet is received; 

reduce transmission of data packets through congested ca^^ ui^ uuu » ^ .,«,,«^efi«n 

nodesofthenetwccktoreduceexistingcongestion.Anothff eadi of the nodt^ detcrmimng whether its congestion 

advantage of the present invention is to continue to provide status is set; and 

an acceptable quality of service to mission critical traffic and ^. each of tiie nodes incrcmcntmg its own congestion 

existing voice and data traffic. counter when the congestion status is set 

Accordingly it is intended by the appended daims to Amethod as reatcd m daim 6, further composing ffie 

coJ^^IS^citionr^th^ 'Tii'^^'^::^^^"''^^^^ 

tme spirit and scope of the invention. For example, a nodal ^o be transmitted from a first no<^ to a second node when 

netw^includes, Vutis not limited to, networklO shown in '^^J^J'^^ri status is set in the first node. 

HG. 2. TTiere aie many other types of nodal networks, . 9.Amrthodasreatedmdami 1, wherem step (a)further 

induding a terrestrial ceUular network or local area network, includes me steps on 

for cxaiLle, for whidi tiie present invention is appUcable. setting a congestion status in a node when congestion is 

What is claimed is; imminent in the node; 

1. A method for managing traffic congestion in a network, 55 dearing tiie congestion status in the node when conges- 

the network comprising a plurality of nodes including a tion is not imminent in the node; 

source node, intermediary nodes and a destination node, the incrementing a congestion counter when the congestion 

method comprising the steps of: status in the node is set and whenever a data packet is 

a) predicting in each of the nodes whether congestion is received; and 

imminent; and 60 decrementing the congestion counter every time a prede^ 

b) determining how many data packets the source node termincd time interval expires. 

can send to tiie destination node when congestion is 10. A method as redted in daim 9, furUier compnsmg tiie 

imminent by determining a credit value, determining steps of: 

whether the credit vahie is less tiian or equal to avaU- dctamining, after flic decrementing stq>, whether the 

able buffer space in the destination node, sending a 65 congestion counter is less tiian zero; and 

message to the source node indicating that the source setting the congestion counter to zero is the congestion 

node can send a numbCT of data packets equivalent to counter is less than zero. 
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11. A method as recited in claim 1. wherein step (bl) 
fuitbcr comprises the step of using a congestion counter as 
an index into a table to determine the credit value* 

12. A method for managing traffic congestion in a 
networiL the network comprising a plurality of nodes includ- 
ing a source node, intermediary nodes and a destination 
node, the method comprising tiie steps of: 

a) predicting io each of the nodes whether congestion is 
imminent by monitoring cuirent buffer usage at each of 
the nodes and determining whether congestion is immi- 
nent based on a con^arison of a profile of the current 
buffer usage with a profile of buffer usage when con- 
gestion is imminent; 

b) determining a credit value; 

c) detcnnining whether the credit value is less than or 
equal to available buffer space in the destination node; 

d) sending a message to the source node indicating that 
the source node can send a number of data packets 
equivalent to the credit value if the credit value is less 
than or equal to the available buffer space in the 
destination node; and 

e) sending the message to the source node indicating &at 
the source node can send the number of data packets 
equivalent to the available buffer space in the destina- 
tion node when the credit value is greater than the 
available buffer space in the destination node. 

13. A method for managing traffic congestion in a 
network, the network comprising a plurality of nodes includ- 
ing a source node, intermediary nodes and a destination 30 
node, the method con^nising the steps of: 

a) setting a congestion status in a node when congestion 
is imminent in the node; 

b) incrementing a congestion counter when the congestion 
status in the node is set and whenever a data packet is 
received; 



10 



15 



20 



25 



35 



c) decrementing the congestion counter every time a 
predetermined time interval expires; 

d) using the congestion counter as an index into a table to 
deteimine a credit value; 

e) detcnnining whether the credit value is less than or 
equal to available buffer space in the destination node; 

f) sending a message to the source node indicating that (he 
source node can send a number of data packets equiva- 
lent to the credit value if the credit value is less than or 
equal to the available buffer space in the destination 
node; and 

g) sending the message to the source node indicating that 
the source node can send the number of data packets 
equivalent to the available buffer space in the destina- 
tion node when the credit value is greater than the 
available buffer space in the destination node. 

14. A destination node comprisiog: 

means for receiving data packets firom a source node; 

buffer coupled to the means capable of storing the data 

packets; and 

congestion controller coupled to the buffer capable of 
predicting when congestion is imminent by determin- 
ing a credit value, determining whether the credit value 
is less than or equal to available buffer space in the 
destination node, sending a message to the source node 
indicating that the source node can send a number of 
data packets equivalent to the credit value if the credit 
value is less than or equal to the available buffer space 
in the destination node, and sending the message to the 
source node indicating that the source node can send 
the number of data packets equivalent to the available 
buffer space in the destination node when the credit 
value is greater than the available buffer space in the 
destination node. 
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